To FaaS or Not to FaaS?
Discuss the pros and cons of FaaS.
How to decide?#
We should ask two significant questions when contemplating whether we should use managed FaaS flavors of serverless computing. Should we use them? And if we should, should it be AWS Lambda, Azure Functions, Google Cloud Functions, or something completely different?
So, should we use managed FaaS? We probably should. But that’s not the right question. We can almost certainly find at least one good example. A more important question is whether managed FaaS can be the solution for a significant percentage of our workload. That’s the question that is more difficult to tackle. To answer it, we first need to establish good use cases for deploying and running functions.
Discussing the use cases#
By now, most of us are using or are experimenting with microservices. They’re smaller applications that are loosely coupled, independently deployable, organized around business capabilities, and owned by small teams. You probably know what they are, and you likely have at least one in your system. You might have even converted everything into microservices by now.
What matters is that you do develop and deploy microservices. If you don’t, functions will almost certainly not work for you. From a very simplistic point of view, they are smaller microservices. We could even call them nano services.
On the other hand, if you do have good use cases for microservices, you might benefit from functions. You could continue the trend of shrinking your applications into the very focused and small entities we call functions.
Some use cases are natural candidates for functions, some might produce a questionable return of investment, and others can be discarded right away. Let’s start with the situations that don’t fit well into the FaaS model.
Against FaaS#
Workload#
If the workload of an application is more or less constant, FaaS is not a good idea. The model is based around a mechanism capable of spinning up an instance of a function for each request. Such an operation is expensive, both in the time required to make it operational and the cost, which is often calculated per request or by time of execution. Even though initialization time is usually measured in milliseconds, if we have relatively constant and massive traffic, wasting time on initialization is not a good idea. If, for example, we have an API that receives thousands of concurrent requests and the volume doesn’t change drastically from one minute to another, we’re likely better off with a different deployment and execution model.
Note: Initialization or the cold-start time has been improved. Service providers managed to reduce it drastically, and they might keep your functions “warm” for a while. Nevertheless, all that has only improved the situation, and didn’t entirely remove the issues with initialization.
There’s one more crucial reason why we’re better off not using FaaS when we have a constant workload. They’re too expensive. As a matter of fact, if we calculate the cost based on CPU or memory utilization, FaaS is much more costly than most of the alternatives. It can be a couple of times of magnitude more expensive. And that’s where the real importance of variable load comes in. If an application’s workload changes drastically from one moment to another, or if our application is only used sporadically, FaaS is way cheaper because we’re usually paying for CPU per millisecond, second, or something in between. But, if we do have constant usage of a resource (e.g., a CPU), it’s usually much cheaper without FaaS. Under certain conditions, the difference can be expressed with a multiplier of five, ten, or even more.
FaaS is very expensive when used extensively. It might be the most costly way to run our applications at scale. From a cost perspective, managed FaaS tends to make sense only when functions are used sporadically, or when there is a considerable variation in the amount of workload, from one moment to another. That doesn’t necessarily mean that FaaS is a bad idea. Those costs could be overshadowed by the benefits and operational or development savings. Nevertheless, the price is not something to be ignored but instead should be factored into the decision of whether to use FaaS or not.
Vendor lock-in#
Another potentially problematic issue is related to vendor lock-in. How important is it to avoid being locked into a single provider? Remember that it’s not only about being locked into a specific compute vendor, but also that there’s not yet a widely accepted standard. We’ll be locked not only into a vendor but into a particular vendor’s product, which is likely very different from other FaaS solutions.
Now, vendor lock-in is not necessarily a bad thing. It’s all about a calculation in which we put benefits on one side and the costs on the other. If the benefits are higher than the cost, it’s okay. If the return of investment we’ll gain by kick-starting our project quickly is sufficiently high enough to warrant the potential losses incurred by being locked in, we should go for it. Just remember that managed FaaS is probably one of the best examples of vendor lock-in we’ve seen so far.
Now, why would it be hard to switch to a different vendor or a different service? Everything we did with the Serverless Framework seems to be simple enough, no matter the vendor. That might lead us to conclude that it should be easy to move from one provider to another. But that would be misleading. We saw a simple example of a single function. When the functions increase in number, it will also increase the number of auxiliary services around them. There’s more code required to glue together all the functions than there is for the functions themselves.
All in all, FaaS is rarely the right solution if any of the following cases are true:
- Workloads are, more or less, constant.
- Workloads are high .
- Lock-in is not desirable.
We can turn those upside down and say that a use case could be the right candidate for FaaS if workloads are variable and not high and if the benefits are greater than the downsides of being locked-in.
Pro FaaS#
Now that we know which situations are not a good fit for FaaS, let’s look at a few examples that might be good candidates.
Static content#
Static content is an excellent candidate for conversion into FaaS. To be more precise, the interface between users and static content can benefit significantly from being functions. Static content, which is not accessed all the time by many users, could be at the top of the list for conversion to FaaS. For example, we could store artifacts (binaries) in an external drive, and spin up an instance of a function whenever we want to push or pull something.
Batch processing#
Batch processing is another excellent example of something that could be served well with FaaS. It could be, for example, an ETL process initiated when we push a change to storage. Or it could be image processing triggered by an upload. It could also be scheduled creation of backups, which we would typically do through a CronJob.
All in all, the best candidates for FaaS are variable or occasional executions of processes that can be encapsulated into small units (functions).
Conclusion#
Does that mean we cannot build whole systems based on FaaS? It doesn’t. We can undoubtedly split everything we have into thousands of functions, deploy them all independently from each other, and glue them together through whatever means our provider gives us. But that might result in a costly decision. The bill from our cloud service provider will likely be much bigger than it should be, and we’ll spend more time in maintenance than we’re used to. That would defy some of the main reasons for using FaaS. It’s supposed to be easier to manage and cheaper to run.
We shouldn’t make a plan to convert everything we have into functions. Heck, we’re still debating whether microservices are a good thing or not. Functions applied to everything would be extreme and would likely result in a miserable failure. Choose good candidates for conversion into functions.
All in all, the use cases where functions are the right choice are relatively small in number when compared with other ways to run applications. But, in good use cases, the results will likely be gratifying.
Deploying AWS Lambda
Choosing the Best Managed FaaS Provider